Business Analyst Community & Resources | Modern Analyst

What is a Big Rock Project?

Adrian M. — Sun, 13 Oct 2024 00:04:00 GMT

A Big Rock Project is a large-scale initiative that plays a critical role in driving an organization’s long-term goals. These projects are strategically important and usually involve significant resource investment, high complexity, and a substantial impact on the organization’s future. Unlike regular projects, Big Rock Projects have clearly defined goals and high stakes, which means they require rigorous planning, broad stakeholder involvement, and formal governance. For example, a Big Rock Project could involve launching a major new product, implementing digital transformation, or expanding into a new market. These initiatives are crucial because they ensure the organization stays aligned with its strategic objectives and remains competitive.

The term "Big Rock" originates from a time management metaphor popularized by Stephen Covey, where the "big rocks" are the most important tasks that must be prioritized ahead of smaller, less critical activities.

Key Characteristics of Big Rock Projects

Strategic Importance - Big Rock Projects are aligned with the organization's mission and long-term objectives. They often drive transformative changes, such as launching a new product line, entering a new market, or implementing a major technological overhaul.

High Complexity and Scope - These projects are typically complex, involving multiple departments, stakeholders, and sometimes external partners. Due to their scope, they require careful planning and coordination.

Significant Resource Investment - Big Rock Projects demand considerable resources, including time, budget, and personnel, often spanning longer timeframes compared to regular projects.

High Impact and Risk - The outcomes of these projects can significantly influence the organization’s growth, profitability, and competitive positioning. Because of their scale, they also carry higher risks.

Defined Objectives and Non-Negotiables- Big Rock Projects have clear goals and success factors that are non-negotiable. Failing to meet these objectives can lead to substantial negative consequences for the organization.

Approach to Managing Big Rock Projects

Managing Big Rock Projects requires a more structured and disciplined approach compared to regular projects:

Upfront Planning - Extensive initial planning and requirements gathering are necessary to ensure all aspects are considered.

Stakeholder Engagement - Involve key stakeholders from various parts of the organization to ensure alignment and buy-in.

Risk Management - Proactively identify and mitigate risks due to the project’s scale and impact.

Formal Governance - Implement governance structures like steering committees to oversee progress and make strategic decisions.

What is a Product Roadmap?

Adrian M. — Sun, 09 Jun 2024 23:45:00 GMT

A product roadmap is a strategic, high-level visual summary that outlines the vision, direction, priorities, and progress of a product over time. It serves multiple purposes, acting as a guide for both internal teams and external stakeholders to understand the future trajectory of a product.

Here are the key components of a product roadmap:

Product Roadmap Vision - The roadmap starts with a clear articulation of the product’s long-term vision. This vision encapsulates the overarching goals and the purpose the product aims to serve. It provides a north star that guides all product decisions and development efforts.

Product Roadmap Strategy - The roadmap details the strategy to achieve this vision, including key themes, objectives, and success metrics. It connects the high-level vision to actionable plans and ensures all stakeholders understand how the day-to-day activities contribute to the larger goals.

Product Roadmap Features and Requirements - The roadmap outlines the major features and requirements that need to be developed. This includes new functionalities, improvements, or even technical upgrades. Each feature is typically aligned with specific business goals or customer needs. The roadmap also highlights which features are most important and in what sequence they will be developed. This prioritization is often based on factors such as market demand, customer feedback, and strategic value.

Product Roadmap Timelines and Milestones - A roadmap provides a high-level timeline for when certain features or objectives will be achieved. This can be broken down into short-term, medium-term, and long-term horizons. Key milestones, such as product launches, beta releases, or major updates, are also indicated. These milestones help track progress and ensure the team remains focused on delivering value at regular intervals.

Here are some key functions and properties of a product roadmap:

Product Roadmap Supports Stakeholder Communication and Alignment - The roadmap is a powerful communication tool. It helps align various stakeholders—including product teams, executives, marketing, sales, and customers—on the product’s direction and priorities. By providing a shared understanding of what is planned and why, the roadmap facilitates collaboration and ensures that all parties are working towards common goals.

Product Roadmaps Are Flexible and Adaptable - A good product roadmap is not set in stone. It is a living document that evolves based on feedback, market changes, and new insights. Flexibility is key to responding to unexpected challenges or opportunities. Regular reviews and updates of the roadmap ensure that it remains relevant and accurately reflects the current state of the product strategy.

Product Roadmaps Are Visual - The roadmap is typically presented in a visual format, making it easier to grasp and communicate complex information. Common formats include Gantt charts, timeline views, and theme-based layouts. Visuals help in quickly conveying the sequence of work, the relationship between different initiatives, and the overall progress against strategic goals.

Portfolios, Programs, and Projects—what’s the difference?

Chris Adams — Mon, 07 Nov 2022 23:29:00 GMT

The term portfolio is used to refer to a collection of programs and projects. These programs and projects are initiated, prioritized, and managed by a company to meet the goals of the business. The term program is used to refer to a single strategic business initiative and groups of one or more related projects that support the business initiative. So one or many related projects can make up a program and one or many programs can comprise a portfolio. There are times when there is no need for all three levels - an organization's list of unrelated projects could simply be called the organization's portfolio.

As a business analyst, understanding each of these three concepts (portfolio, program, and project) and how your project fits into the greater program and ultimately portfolio of projects can help you understand many of the decision made by executives. If you know that your project has a high priority within the portfolio, your requests for additional resources have a much higher likelihood of being approved compared to a request from a low priority project. Similarly, if your project has a low priority, resources could be pulled to support higher priority projects or your project may be cancelled altogether, even if it was on track and on budget.

Understanding other projects in the portfolio and their relation to your own can also help the business analyst make better decisions. Instead of making decisions based strictly on a myopic view of your own project, a good business analyst will consider the pros and cons that each decision may have on other projects belonging to the same program. In this way, the business analyst is ensuring that they are delivering the optimum solution for the project and the company as a whole.

What is Scope Creep and how do you manage it?

Chris Adams — Mon, 10 Oct 2022 17:30:00 GMT

Scope creep occurs when additional features are slipped into a project after the project scope is defined and the project has started. The intent is generally good with the hope of making the delivered product better, but these changes can lead to the project running over time and/or over budget. How you manage scope creep depends on the type of project.

What are the 4 Stages of Product Life Cycle (PLC)?

Adrian M. — Mon, 11 Jul 2022 01:39:00 GMT

As a product manager, you want to have the right expectations when managing the lifecycle of a product. There are many questions which should be considered at the outset: Will the product most likely be a hit from day one? Will there be any challenges that I should expect along the way? Will the product live forever?

In order to develop the right expectations one needs to know the stages of a product's life cycle.

The 4 stages of Product Life Cycle (or PLC) are:

Introduction Stage

Growth Stage

Maturity Stage

Decline Stage

Each phase of the product life cycle is generally marked by specific characteristics:

	Introduction	Growth	Maturity	Decline
Sales	Low	Increasing	Peak	Decreasing
Customer Acquisition Cost	High	Decreasing	Lowest	Increasing
Profitability	Loses	Increasing	Highest	Decreasing
Customer Base	Few	Increasing	Mass Market	Decreasing
Competitors	None or Few	More	Most	Decreasing

Being aware of the 4 stages of product life cycle and their distinctive characteristics help the product managers and business owners to not only have realistic expectations but to also anticipate changes in the market landscape and, if possible, introduce innovation and product changes in order to lengthen the duration of the maturity stage.

For example, the product would be enhanced and re-introduced as a 2.0 version to the same customer base. The product could be re-purposed and marketed for a new use or a new industry. The product could be marketed to a new set of customers such as a new state, or a new country.

What is a RAID log and how is it used?

Chris Adams — Sat, 08 Jan 2022 21:54:00 GMT

Business Analysts often pull double-duty as project managers. As a project progresses, risks, issues, and other events come up that impact the project. A RAID log is an effective tool for tracking items, and it provides people with a consistent place to look for answers.

What is an Impact Map, what makes it robust, and why should an experienced BA know how to create one?

Chris Adams — Fri, 10 Sep 2021 20:45:00 GMT

Impact maps are a powerful tool in the agile BA toolkit. First introduced by Gojko Azdic, a Strategy Consultant, in 2012, Impact Maps (IM) are a fast and straightforward strategic planning tool. They provide a high-level graphic view of business goals and how they may be achieved. Several free and paid tools can be used for creating Impact Maps. It facilitates collaboration between technical teams and business stakeholders as well as being an enabler for getting all stakeholders aligned regarding goals and the strategies for achieving them.

What does it mean to be a strong meeting facilitator?

Chris Adams — Mon, 09 Aug 2021 15:22:00 GMT

When looking for Business Analyst roles, many job descriptions are now looking for people who, you guessed it, have excellent facilitation skills. So, in hopes of sparing you any surprises in an interview, I thought I'd give you my words of wisdom on the subject.

Fortunately, you've been practicing facilitation, like I have, without realizing it. So it won't be too hard to catch on…

Do you apply your project management skills outside of work?

Chris Adams — Sun, 11 Jul 2021 01:25:00 GMT

So how is this all relevant in an interview setting? First, it shows your passion for the job runs deep, that you’re all in. Second, it shows that you understand anything can be broken up into manageable pieces and completed on a short timeline. The skills you have are transferable and adaptable. Some benefits of using your project management skills in your personal life setting include:

Skills mastery
Gap filler. Resumes can’t account for most of your “off the clock” time, but an interview can. It is helpful when pivoting your career. In either case, you can show that you have what it takes.
With non-disclosures and proprietary property, you are very limited to the amount of work you can showcase. Performing some of the skills outside of the job helps. You can have a “portfolio” of your work accessible online, so the hiring manager has the opportunity to review it.
It shows a personal side. It is a way for the hiring manager to know you outside of work.

What is the Cone of Uncertainty?

Chris Adams — Sat, 10 Jul 2021 15:05:00 GMT

The Cone of Uncertainty is a term often used in project management to describe the phenomenon by which project unknowns decrease over time. As the project proceeds and more research and development is completed the amount of uncertainty decreases, eventually approaching zero. Project unknowns, or uncertainty, largely correlate to variances in project estimates. Plotting these variances over time creates a cone or funnel shape (variance percentages shown are only examples, values may vary).

How do solve the problem of endless meetings with few results?

Chris Adams — Fri, 07 May 2021 16:10:00 GMT

There are a couple of ways you can ensure that your meetings are producing results rather than endless discussion. Here are two options that can work, each catering to a different organizational environment.

What is a Scrum of Scrums and what are its benefits?

Chris Adams — Mon, 03 May 2021 21:19:00 GMT

You manage a team of Project Managers and Business Analysts.They are all assigned different projects, but you come to realize they all intersect at one business application.

All teams conduct their meetings throughout the project to ensure it's going according to the project charter or their sprint goals. Some are using status meetings, and others are running daily scrums.

How do you ensure synchronization among the teams and that an accidental change does not compromise the business application? That there are no impacts or impediments to a smooth delivery? What is your approach?

What is a stakeholder needs assessment?

Chris Adams — Thu, 04 Feb 2021 15:27:00 GMT

Stakeholder analysis involves identification of individuals and organizations that have some form of stake or interest in the project outcomes, and assessing the particular needs of each stakeholder group. The stakeholder needs assessment is conducted early in the project, so that steps can be taken to effectively manage their interests and expectations throughout the project.

What is your "Definition of Done"?

Chris Adams — Wed, 02 Dec 2020 20:30:00 GMT

The Scrum Guide's definition of Done (DoD) is shared and agreed upon within the Scrum team. An item is "Done" when a backlog item/increment is potentially shippable. Where, at the end of a Sprint, you must have something complete and ready to ship, but shipping is not required.

What is Total Cost of Ownership (TCO) and why is it important?

Chris Adams — Sun, 12 Jul 2020 17:30:00 GMT

Total Cost of Ownership is an estimation of the cost of a new technology solution that considers the full cost of acquisition plus ongoing maintenance over a specific period of time, usually 5 to 10 years. Because the cheapest solution to acquire (whether purchase or custom-developed) is not always the cheapest solution to maintain over the long-term, TCO is a good way to compare alternative solutions from a financial standpoint and to ensure that the organization is prepared and able to cover the cost of a new solution over the long term.

Is it really necessary to document the business vision at the start of a project?

Chris Adams — Mon, 08 Jun 2020 16:55:00 GMT

The business vision serves as a foundation that drives, guides and unifies the project from beginning to end. It may be captured in a 1-page Vision statement or a formal Vision document, depending on the size and complexity of the project.

Describe some key differences between business automation and business transformation

Chris Adams — Mon, 11 May 2020 00:34:00 GMT

The differences between business automation and business transformation can be understood by examining them across a few key areas.

Focus
Approach
Who/What Drives It
Breadth of Impact
Scale of Investment

What approach do you use to evaluate the impact of a requirement change on the project?

Chris Adams — Sun, 10 May 2020 22:05:00 GMT

Business Analysts need to show that they approach any issue in a structured and methodical manner. This includes evaluating the impact of changing requirements on a project. When a requirement change occurs, business analysts often assist the project manager in the evaluation of it’s impact. Together they determine the appropriate course of action. Proposed changes should be evaluated based on how they might impact eight distinct project areas:

How do you deal with management who constantly tries to reduce your estimated analysis hours?

Chris Adams — Fri, 10 Jan 2020 18:00:00 GMT

A good rule of thumb is that no single task should be greater than 40 hours when estimating. And if you know that your management has a habit of pushing back hard on estimates make sure that no single task is greater than 20 hours, with most being less than 8-12 hours.

What is a Team Competency Assessment and why might it be used?

Chris Adams — Sun, 08 Dec 2019 17:30:00 GMT

The success of any project is dependent on a number of factors, but ensuring you have the right team competencies (people and skills) is imperative. When a team is put together from scratch, ensuring that the team has the appropriate competencies to meet the needs of the organization is usually the paramount concern. Though it's not always analyzed in a formal way. However many operations and technology teams exist as a permanent group within an organization. As projects arise, resources (people) are assigned to various teams to complete the current projects. In this instance, without a formal assessment, it's common that the assembled teams lack the necessary skills for success.

Performing a team competency assessment can reveal any team weaknesses so that new or additional team members with the required skills can be sourced.

What is Program Increment Planning as it applies to the Scaled Agile Framework?

Chris Adams — Mon, 11 Nov 2019 18:34:00 GMT

Program Increment (PI) Planning is one of the biggest and most important events in the Scaled Agile Framework (SAFe). It aims to set the direction and activities for the Release Train’s next 8-12 weeks of work through a large scale planning session. To understand PI Planning properly we need to first take a step back and understand three key terms; SAFe, Agile Release Trains and Program Increments.

What is a Sprint in Scrum/Agile?

Chris Adams — Mon, 11 Nov 2019 17:28:00 GMT

A sprint is a short, defined period of time that a team uses to organize their work cycles - it is the key feature of Scrum (the most popular Agile framework) and is used by thousands of teams around the world.

Sprints last between one and four weeks, but two week long sprints are the most common. Throughout this article I’m going to refer to two week long sprints for the sake of simplicity.

Sprints start with defining the goal and scope. This shouldn’t change during the sprint, once it has been defined. The team then go about completing the tasks of the sprint. By the end of the sprint the aim is for the team to have completed everything to achieve their goal.

What is a Product Manager?

Chris Adams — Sun, 07 Jul 2019 16:00:00 GMT

The role of the Product Manager resides at the intersection between business, technology and user experience. The paramount responsibility of a Product Manager is to ensure that the product they manage (software, service, or other tangible product) creates value for the business. In turn, to create value for the business the product needs to be of value to customers or to internal business employees.

What is the 4-D framework for Time Management?

Chris Adams — Sun, 09 Jun 2019 21:50:00 GMT

Competing demands on our time ensure one constant; we rarely have enough time to complete everything we would like to do. Time management skills are critical to our success and productivity. The 4-D framework is a simple, yet effective, technique for determining how to react to requests on our time.

The 4 Ds are: Do, Defer, Delegate, and Drop (Delete). It can often be helpful to approach the framework in the reverse order listed to whittle down the list of requests.

What is the “First-Time First-Use Penalty”?

Chris Adams — Sun, 09 Jun 2019 19:30:00 GMT

The First-Time First-Use Penalty states that the first time undertaking anything new it’s impossible to know how long it will take to complete. A fairly simple principle that absolutely plagues the IT industry due to the complexity and variability of IT systems. IT systems are so unique and so multifaceted that the constant movement of its variables create an incredible challenge to estimating costs accurately.

What strategies could be used on a project to deal with undesirable (negative) risks?

Chris Adams — Sun, 07 Apr 2019 20:15:00 GMT

Common strategies for dealing with negative risks include Acceptance, Transfer, Avoidance, Mitigation

How do you effectively manage time, both personally and at an organizational level?

Chris Adams — Thu, 07 Feb 2019 17:20:00 GMT

Companies manage their capital budgets with intense rigor. So why do so many fail to manage their time with the same level of commitment and structure?

It has been found that on average executives spend 2 full days each week just attending meetings. To make matters worse the last 40 years have shown an explosion in communications. Executives received only about 1,000 external communications per year in the 1970s. This has ballooned to 30,000 communications per year in the 2010s due to emails, phone calls and virtual collaborations with people external to the organization.

By applying rigor to the way companies view time allocation, organizations have the opportunity to free up as much as 20% of their collective hours.

What are Story Points and why use them?

Chris Adams — Sun, 14 Oct 2018 16:40:00 GMT

Story points are a unit of measure used to estimate the relative size and complexity of user stories in agile development. If one user story is 1 point and another is 2 points then the 2 point user story is expected to take twice as much effort to develop as the first.

What is Planning Poker?

Chris Adams — Sun, 14 Oct 2018 16:25:00 GMT

Planning Poker is a consensus-based technique for estimating effort. It is primarily used in agile development to estimate the size of user stories, but can be equally as powerful for estimating effort of key tasks in a project plan using a traditional work breakdown structure.

What is a Minimum Viable Product?

Chris Adams — Mon, 12 Mar 2018 17:05:00 GMT

A Minimum Viable Product (MVP) refers to a product that has just enough features to reasonably demonstrate its viability to a group of stakeholders in order to receive feedback. By greatly limiting the scope of the product to its absolute minimum feature set the product development team is able to limits costs and risks.

What is a RACI Matrix?

Chris Adams — Sun, 11 Dec 2016 19:09:00 GMT

RACI Matrix is the name given to a table which is used to describe the type and degree of involvement that stakeholders have in completing tasks or deliverables for a project or business process. Also sometimes called the Responsibility Assignment Matrix or Linear Responsibility Chart, it is a common tool used by business analysts and project managers for establishing roles and responsibilities early on in a project. In this way it reduces project risk and sets expectations about the level of involvement that is expected by various stakeholders.

What is meant by Forming, Storming, Norming, and Performing?

Chris Adams — Sun, 12 Jun 2016 19:01:00 GMT

The phrase Forming, Storming, Norming, and Performing was coined in 1965 by psychologist Bruce Tuckman. He described that most teams follow a consistent path from the point when they are first assembled to the time when they become a highly proficient, highly effective group. This path leads them through four distinct stages; Forming, Storming, Norming, and Performing.

What is a Daily Scrum Meeting?

Chris Adams — Sun, 07 Feb 2016 17:50:00 GMT

The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting where a team (ideally around 6-9 members) meets and updates one another on the work that has been completed and what will be completed next. It provides an update to the entire team while providing a daily refocus for each team member as they deliver their status.

What is a Burn Up Chart and how does it differ from a Burn Down Chart?

Chris Adams — Sun, 10 Jan 2016 22:49:00 GMT

A Burn Up Chart is a tool used to track how much work has been completed, and show the total amount of work for a project or iteration. It’s used by multiple software engineering methods but these charts are particularly popular in Agile and Scrum software project management. The completed work and total work is shown on the vertical axis in whatever units a project team feels works best, i.e., work-hours, work-days, story points, or any other work unit. The horizontal access displays time, usually in days, weeks, or iterations (sprints).

How does the term Velocity apply to an agile project?

Chris Adams — Sun, 10 Jan 2016 17:00:00 GMT

The Velocity of an agile project describes the speed, in story points, at which user stories are completed from sprint to sprint. Formulaically, this is the ratio of completed story points over the duration of the sprint.

Velocity = Completed Story Points / Sprint

Example: If a team completes 150 story points over the course of 3 sprints then the average Velocity = 150/3, or 50 Story Points/Sprint.

Pretty straight forward. So how is velocity useful?

Calculating the team’s velocity after the first sprint provides the information necessary to assign user stories to future sprints, as well as estimate the time required to complete all of the sprints required to deliver the desired functionality. The team velocity can also be used as a starting benchmark from which improvements in team efficiency can be made. This may be by removing friction within processes or team dynamics, or by eliminating or improving on any number of other things which slow the rate of progress

--
Chris Adams
LinkedIn Profile

What is a Work Breakdown Structure?

Chris Adams — Mon, 12 Oct 2015 18:25:00 GMT

The Work Breakdown Structure (WBS) documents the subdivision of tasks and effort required to complete an objective or project. It is most often depicted as a tree structure where high level tasks break down into lower level tasks.

Describe the V-Model

Chris Adams — Sun, 13 Sep 2015 19:27:00 GMT

The V-Model is essentially an extension of the waterfall model. The system design and development stages of Requirements Gathering through Coding are shown as the downward sloping left side of a “V”, with the Testing stage being broke into its constituent phases of Unit Testing, Integration Testing, System Testing, and User Acceptance Testing creating the upward sloping right side of the “V”. Each system design and development stage on the left corresponds with a testing stage on the right. Each phase of testing is planned in parallel with each of the corresponding system design and development stages to ensure that the appropriate effort and attention is allocated.

What is the Eisenhower Matrix?

Chris Adams — Sun, 11 Jan 2015 21:52:00 GMT

Business Analysts are often working within organizations that are all about dealing with the latest crisis. Instead of focusing on what’s important to the business from a strategic perspective, everyone is busy putting out "fires".

The Eisenhower Matrix is a prioritization tool that helps the business analyst refocus on what should be handled when, and who should focus on them. This method gets it's name because it is said it was used by U.S. President Dwight D. Eisenhower who was adept at time management. The quote, "What is important is seldom urgent and what is urgent is seldom important" is attributed to him.

The Eisenhower Matrix is a simple 2x2 matrix. The 2 rows are labeled "Not Important" and "Important", while the columns are labeled "Urgent" and "Not Urgent". Items will fall into 1 of 4 quadrants.

Quadrants:

Urgent and Important - Deal with these immediately and give them your utmost attention.
Not Urgent but Important - Determine when these will be done.  These are items that move you towards your strategic objectives.
Urgent but Not Important - These tend to be trivial time wasters and distractions such as phone calls, emails, etc. There importance is low but they need to be dealt with at that moment. Delegate these to others.
Not Urgent and Not Important - These items may never get done and it's not that big of a deal. They are low on the priority list.

--
Chris Adams
LinkedIn Profile

What is force-field analysis?

Chris Adams — Fri, 07 Mar 2014 02:15:00 GMT

Force-field analysis is a technique for assessing an organization’s readiness for change, by identifying and evaluating the forces that support a proposed change and the forces that oppose it. The proposed change is pictured in the centre of a force-field diagram, with supporting forces and opposing forces listed on opposite sides. The strength or influence of each force is estimated, usually on a scale from 1 to 5.

The ‘force field’ can then be analyzed to determine if there is sufficient support to move the change forward, and to identify ways in which the supporting forces can be strengthened and / or opposing forces weakened.

--
Sandy Lambert
Business Architect
LinkedIn Profile

Should user stories be created to plan for system maintenance and support?

Chris Adams — Thu, 06 Jun 2013 05:07:00 GMT

This question is likely rooted in a misunderstanding of what agile development is all about. Agile project teams are intended to be assembled for specific projects. Once a certain amount of product planning, backlog planning, and sprint planning takes place, the first sprint kicks off. From that point on, the goal of the agile team is to deliver incremental user value at the end of each sprint and to maximize the velocity at which the team delivers such value (Velocity is just a fancy term for the number of Story Points completed during a sprint, and Story Points are the unit of measure used to size user stories relative to each other).

None of this means that the velocity incorporates all costs associated with developing the features defined by the user stories. Overhead still exists within agile teams. In fact, story points don’t track absolute hours at all. They are intended to show the relative size and complexity of user stories for prioritization and sprint planning purposes.

Typically Project Management and Product Management time is lumped into overhead costs. One major reason for this is that much of the work done by these roles cannot map one to one with user stories. There is a lot of project management work and product management work that occurs which never results in value to the user. For example, a product manager may document or lead the effort to create a series of user stories that, once estimated, end up being prioritized out of existence. Perhaps the decision is made that there isn’t enough value in the user stories to have them developed. So this is one example where the time spent by people who work on or with the agile project team isn’t tracked by a user story.

So back to our original question, should distinct user stories be created for maintenance and support. The short answer is no. Once a system or application is developed, there will continue to be hardware and infrastructure management that needs to occur. Someone needs to monitor server loads, bring new virtual servers online when system load rises to a point where server degradation begins to occur, etc.

The slightly longer answer is that while user stories should never be created solely for system support or maintenance, support and maintenance tasks can sometimes be sized into new user stories when it makes sense. If it’s known in advance that a feature defined within a user story is going to require a significant amount of infrastructure to support the new functionality, then the time require to set up and configure new servers should be included in the user story estimate. Of course, it may make sense to distribute this time over several user stories that require the new back end resources. So, really it depends on whether the work is a result of the user story itself.

It’s also worth noting that refactoring is a natural and necessary part of agile development. Refactoring describes the act of restructuring the internal structure of existing code without impacting the external functions of the system as viewed by the user. Refactoring may be needed to improve non-functional aspects of a system such as response times, or refactoring may be required to support a new feature that can’t be supported with the current architectural structure. In agile projects, refactoring is expected and should be planned for. The incremental cost of refactoring should be spread across the impacted user stories whenever possible. User stories contain acceptance tests that need to be retested once the refactoring occurs to ensure that the existing functionality hasn’t been broken.

What are the advantages of fixing bugs early?

Chris Adams — Sun, 06 Jan 2013 18:36:00 GMT

Once a bug is identified there are a number of advantages to fixing it as quickly as possible.

Bugs lead to inaccurate status updates and estimates. It’s difficult to estimate the full impact to the project schedule of outstanding bugs. Inevitably, as the project progresses bug fixes and the identification of new bugs seem to take up a larger and larger percentage of the developers’ time. It’s quite common for projects to near the 85-90% completion mark only to hover around that level for some time as bugs continue to be discovered and fixed.

Discussing bugs is an inefficient use of time. Tracking bugs, prioritizing when they should be fixed, and determining how much time it will take to fix them is non-productive. The longer bugs remains unfixed the more time is spent reviewing them during each planning and status meeting.

Unfixed bugs hide other bugs. You can fix one bug only to discover another that wasn’t apparent until the first bug was fixed. Even worse, the new bug that you uncover may be more severe than the original bug and now it’s being fixed much later in the development process.

Bugs make it hard for a team to know if they are reviewing unfinished work or if a bug really exists. Since testing occurs at all stages of development, testers and users often will be reviewing unfinished features within and application. As they stumble across bugs they must try to assess whether it’s an actual bug or whether its just a feature that isn’t fully coded yet.

Unfixed bugs suggest to the team that quality isn’t important. By allowing unfixed bugs to linger and not placing an appropriate emphasis on them, the root causes of bugs (poor specs, poor coding) persist. This creates an environment where mediocrity becomes the status quo.

Unfixed bugs misappropriate the time spent by testers. Good developers should be constantly unit testing their own code. However, when mediocre work becomes the status quo too much is left for the testers to discover. This moves the attention of the testers away from finding the more difficult and complex bugs to finding surface level bugs that should have been fixed prior to QA. Ultimately, this causes testing fatigue and increases the chance the testers will fail to uncover other more complex bugs.

Fixing recent and familiar code is easier for developers. If the developer hasn’t touched the code in several months and then needs to return to it to fix a bug, it takes more time to re-familiarize themselves with the code compared to fixing the bug shortly after the feature was coded.

All of these reflect the advantages of fixing bugs early and quickly.

Explain Kurt Lewin’s Model of Organizational Change

Chris Adams — Sun, 13 Mar 2011 22:21:00 GMT

If there is one thing that you can be certain of in business today it’s change. Kurt Lewin, a physicist and social scientist, defined a model for organizational change as far back as 1947. This model is still taught today in many business schools as part of the change management discipline.

Lewin used an analogy of changing the shape of a block of ice to convey his theory. If you want to change the shape of a block of ice you must first melt it or break down its existing structure. Once it’s unfrozen, it becomes liquid and can be changed by guiding it in any direction you desire. Using a mold, you can cause it to take on a different shape from its original state. Finally, you freeze the liquid within the mold to crystallize it into its new shape. This is how Kurt Lewin explained his influential three-stage model of organizational change. Here are some key points to consider when thinking about three stages of change (Unfreeze, Change, Freeze).

Unfreeze

Before you can begin changing an organization in any meaningful way you need to overcome the inertia of the existing way of doing things. This starts by challenging many of the beliefs, attitudes, and behaviors of people within the organization. As Lewin put it, “Motivation for change must be generated before change can occur. One must be helped to re-examine many cherished assumptions about oneself and one’s relations to others.” You are breaking down the status quo. During the unfreezing process everyone feels that things are becoming off balance. This feeling becomes a strong motivator for people to seek out a new equilibrium. During this stage, you need to sell the benefits of the change. The more people that recognize that the change needs to occurs the more likely it will be successful.

Determine what needs to change
Sell the benefits of the change to everyone involved (this includes getting support from upper management)
Specifically address any doubts or concerns

Change

Once the organization has gone through the unfreeze stage, effective change can begin within the organization. People begin to look for new ways to do things and support the new direction. Time and frequent communication are two key factors for the change to occur. People need to understand the changes as they occur and feel that they are part of the change. Some take a long time to recognize the real benefits. This can lead to fear and rumors that need to be handled quickly.

Involve people in the process and empower them
Communicate frequently
Dispel rumors quickly

Freeze

Once the changes have taken effect, the next stage is to freeze or crystallize the changes within the organization. Putting the proper processes and the organizational hierarchy in place to manage them is important to ensure this happens. Since change is always occurring, some might ask why bother to freeze things. Why not stay in a constant state of change? Constant change, without freezing things in place at least momentarily, leaves people without a clear sense of direction. It becomes more and more difficult as time goes on to convince people that something needs changing if you don’t give the most recent changes time to fully crystallize. Also, taking the time to celebrate the successful completion of changes within the organization provide everyone with a feeling of reward and gives them closure.

Develop processes to anchor the changes into the culture
Provide clear communications, support and training
Celebrate the successful completion of changes

--
Chris Adams
LinkedIn Profile

What are Use Case Points?

Chris Adams — Sun, 13 Mar 2011 22:02:00 GMT

Use Case Points are similar to Function Points in many ways as they are used to size and estimate the cost of work on systems. Use Case Points are a normalized unit of measure used to:

Quantify the amount of business functionality a system provides business users

Estimate the cost to develop a system or set of features based on the number of use case points it supports

Determine how costly a system is to maintain based on the number of use case points it supports

The number of Use Case Points is derived from factors such as:

The number of system use cases and the complexity of the use cases

The number of system actors

Non-functional requirements that are not captured as use cases but that have an overall impact on system complexity

The project environment including the architectural framework, programming language, team structure and efficiency, etc

The system’s Use Case Points are calculated as follows.

First, to arrive at an Unadjusted Use Case Weight (UUCW), the analyst counts the number of user and system activity steps that occur in a use case (including its main and all of its alternative flows and extensions). The term activity step is specifically used because this does not include the decision step such as determining if an entry is valid (yes or no). It would, however, consider the system’s response to the invalid entry. The number of activity steps is used to assign a complexity to each use case. The number and complexity of each use case are then combined to determine the system’s Unadjusted Use Case Weight. UUCW = (# of Use Cases) x (Weight based on complexity)

Complexity	#of Activity Steps	Weight
Simple	1-3	5
Average	4-7	10
Complex	8 or more	15

Next, the Unadjusted Actor Weight (UAW) is calculated. Each system actor is counted and assigned a complexity level. A system actor interacting with the system under consideration through a standard API is considered simple. As human actors using GUIs are introduced, or as various data mappings have to occur between an Actor and our system, the complexity increases. Each actor and its complexity is used to arrive at the Unadjusted Actor Weight. UAW = (# of Actors) x (Weight based on complexity)

Actor Type	Example	Weight
Simple	Another system via an API	1
Average	A person via a text-based interface	2
Complex	A person via a GUI	3

Adding the UUCW and UAW together gives you the Unadjusted Use Case Points (UUCP).

The results of Use Case Points are typically more consistent when use cases are written at a similar level of granularity across the system.

Next, the Use Case Points method accounts for Technical and Environmental Factors. There are 13 standard Technical Complexity Factors (TCF) that are considered and each has a predefined weight. They are:

Technical Complexity Factors	Weight
Distributed system	2
Performance objectives	2
End-user efficiency	1
Complex processing	1
Reusable code	1
Easy to install	.5
Easy to use	.5
Portable	2
Easy to change	1
Concurrent use	1
Security	1
Access for third parties	1
Training Needs	1

Similarly, there are 8 Environmental Factors (EF) that are consider, each with its own weight.

Environmental Factors	Weight
Familiar with the development process	1.5
Application experience	.5
Object-oriented experience	1
Lead analyst capability	.5
Motivation	1
Stable requirements	2
Part-time staff	-1
Difficult programming language	-1

For each of the Technical and Environmental Factors a value between 0 and 5 is assigned to represent the degree of influence the factor has on the particular project and system being designed. Some will have no influence (0) while others will have a very large influence (5). For example, if it’s a highly distributed system, the influence for the TCF #1 might be a 5, resulting in a value of 10 (TCF Weight x Influence).

By multiplying each factors weight value by its influence value and summing them all together the TF and EF can be determined.

Finally the Adjusted Use Case Points (UCP) is calculated using the formula: UCP = UUCW x TCF x EF.

What is Function Point Analysis?

Chris Adams — Sat, 12 Feb 2011 01:11:00 GMT

Function Point Analysis (FPA) refers to the practice of using function points to size and estimate the cost of work on systems. Function Points are a normalized unit of measure used to:

Quantify the amount of business functionality a system provides business users
Estimate the cost to develop a system or set of features based on the number of function points it supports
Determine how costly a system is to maintain based on the number of function points it supports

To state things differently, Function Points are good for answering questions like:

How big is system “A”? Is system “A” bigger than system “B” and by how much? (It answers these in terms of features)
How much will it cost me to build system “A”?
If I’m paying $500,000/yr to maintain system “B” is that cost effective?

Function Points, being a normalized unit of measure, provides an apples-to-apples comparison of systems and the costs associated with building and supporting them.

This method of measuring systems was first developed in 1979 by Allan Albrecht of IBM. Today it is supported by a group called the International Function Point User Group (or IFPUG for short).

To count the number of function points that a system possesses, a skilled practitioner first categorizes each feature into one of five types (outputs, inquiries, inputs, internal files, and external interfaces). Then a complexity is assigned to each feature. Finally, a number of function points can be assigned to each feature. Certain types of system also have additional function point adjustment factors that are used. The end result is a single number for the entire system called a Function Point Index. Based on this value and historical function point data, the cost to develop the system can be estimated.

FPA brings structure and rigor to a process that is often very subjective. However, there are a number of potential challenges that are often voiced when discussing the merits of FPA.

Counting Function Points can be a tricky task to do well. Getting consistent results is a challenge unless you are a skilled practitioner at counting function points. There is a sizable “Function Point Counting Practices Manual” available to direct the practitioner in this exercise.
FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.

While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try to compensate for these challenges.

What is a Vision Document?

owizard — Sun, 13 Apr 2008 20:40:00 GMT

"What is a Vision Document? What are the typical sections in it? Is it different from a Business Case?"

The Vision

Let's discuss first what is considered the "Vision". In general, the Vision represents the end user's or customer's ideas and views of the software product to be developed. Think of the vision as the "idea". In an entrepreneurial environment, the entrepreneur starts with an "idea" which is later turned into a tangible product, service, etc.

Same is the case with software projects; they all start with an idea or vision related to the types of needs that might be addressed by a system having certain features.

The Vision Document

Many organizations capture the Vision in a "Vision Document" which generally contains the key business needs and features of the system from the stakeholder perspective. The Vision Document is simply a mechanism to put down on paper "the idea".

There are many different types of templates for a Vision Document depending on the methodology, organization, project size, etc.

The Business Case

Yes, the Business Case is different than the Vision. Whereas the Vision represents the "idea", the Business Case is the "rationalization" as to why the Vision is a good idea and how the Vision will be implemented. The Business Case begins the discussion, at the high level, on how the project might be implemented: cost, resources, timelines, etc.

The Vision Document Template

The Vision Document defined by RUP (Rational Unified Process) includes the following sections:

1. Introduction

1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview

2. Positioning

2.1 Business Opportunity
2.2 Problem Statement
2.3 Product Position Statement

3. Stakeholder and User Descriptions

3.1 Market Demographics
3.2 Stakeholder Summary
3.3 User Summary
3.4 User environment
3.5 Stakeholder Profiles
- 3.5.1
3.6 User Profiles
- 3.6.1
3.7 Key Stakeholder or User Needs
3.8 Alternatives and Competition
- 3.8.1
- 3.8.2

4. Product Overview

4.1 Product Perspective
4.2 Summary of Capabilities
4.3 Assumptions and Dependencies
4.4 Cost and Pricing
4.5 Licensing and Installation

5. Product Features

6. Constraints

7. Quality Ranges

8. Precedence and Priority

9. Other Product Requirements

9.1 Applicable Standards
9.2 System Requirements
9.3 Performance Requirements
9.4 Environmental Requirements

10. Documentation Requirements

10.1 User Manual
10.2 Online Help
10.3 Installation Guides, Configuration, and Read Me File
10.4 Labeling and Packaging

A. Feature Attributes

Why is it important to prioritize requirements?

Analyst Kris — Wed, 20 Feb 2008 10:33:00 GMT

The main reason why it is important to prioritize requirements is because like most of us, organizations have finite resources (money, time, employees, etc.)

Since not all requirements can be implemented right way, the business needs to determine which requirements should be addressed first. Without going into the details on how to perform requirements prioritization, we should point out that the ultimate determining factor is ROI (return on investment).

How much money am I going to make/save if I implement this requirement. Yes - most business are about money but this works even for non-financial driven requirements (such as how many more people am I going to convince to vote for candidate X if I implement requirement # 1 vs. requirement # 2).

In order to determine the ROI the business analyst needs to look at a number of factors (aka attributes of each requirement) including but not limited to:

how important (biggest savings or gain) is the requirement to the business that is, if the cost to implement each requirements was the same, what would be the order of execution,

how much would it cost to implement each requirement,

how much would the business lose if they don't implement a given requirement (for example if the requirement is as a result of a law how much could it cost the company if it were to get into litigation for now complying with the law?),

how long would it take to implement a given requirement; note that longer duration does not necessarily mean increased cost, however longer duration could mean a lost business opportunity which, in turn, might call for not implementing the requirement in the first place.

etc.

Additional resources:

First Things First: Prioritizing Requirements

Requirements Prioritization Introduction

How would you control the scope of a project?

Guy Beauchamp — Mon, 10 Dec 2007 13:25:00 GMT

Every requirement (be it at high, medium or low level, every process step and control flow, every entity, attribute and relationship) must be contributing to one or more SMART objectives for a project. If a new requirement at any level is proposed it must be mapped to the objective(s) it contributes to. If it does not map it means either an objective is missing (and therefore a significant amount of analysis is also missing) or the requirement MUST be out of scope as it does not contribute to project success.

SMART stands for:

Specific
Measurable
Achievable
Realistic
Traceable and Time-Bound

What is the role of the Business Analyst (BA), at each point in a typical project or programme of work?

Guy Beauchamp — Mon, 10 Dec 2007 13:14:00 GMT

To consider the scope of the business analyst role it is helpful to consider the chain of reasoning that leads from the statement of a problem to implementation of solutions.

This chain involves 10 groups of users:

Owners

Strategists

Sponsors

Programme Managers

Project Stakeholders

Design Analysts

Solution Builders

Solution Builders & Business

Project Managers

Users

Click "Scope of the Business Analyst role" image for larger version